Within any computer system, and particularly those that include an enterprise-level software stack such as an application server running atop a virtual machine, as network speeds increase, it becomes increasingly important to optimize the path which data travels within the stack. Extra data copy operations can significantly reduce the performance of the system.
In the context of Java, and Java Virtual Machines (JVM), one approach that can be used to eliminate extra copies of objects within the Java input/output (I/O) libraries is to allow socket I/O calls to access the Java memory space or heap directly. However, in a JVM, since the heap is garbage-collected, the objects therein (in the case of I/O, a byte buffer) can move, which in turn can cause problems with the I/O.
Different virtual machine technologies have attempted to address this problem. For example, object pinning, as is used in the JRockit JVM, provides a Java language interface that allows the user to pin certain objects, thus preventing those objects from being moved by the garbage collector during garbage collection. Since the object does not move, the I/O can be performed directly. The downside of this approach is that it imposes a nontrivial overhead on allocation and garbage collection. As another example, a garbage collection (GC) locker feature, such as is used in the Hotspot JVM, provides a global locking mechanism that allows the user to temporarily disallow garbage collection from taking place, thus guaranteeing that the receiving object in the heap does not move. The downside of this approach is that the global lock is a single contention point, and therefore reduces system scalability; if the lock is held and the young generation is full, then subsequent allocation goes slow path to the old generation. These are the general areas that embodiments of the present invention are intended to address.